Skip to content

products/adsp: Add early kernel debug info#426

Open
Brandon-Hurst wants to merge 1 commit intoanalogdevicesinc:mainfrom
Brandon-Hurst:adsp/add-debug-guide
Open

products/adsp: Add early kernel debug info#426
Brandon-Hurst wants to merge 1 commit intoanalogdevicesinc:mainfrom
Brandon-Hurst:adsp/add-debug-guide

Conversation

@Brandon-Hurst
Copy link
Copy Markdown
Contributor

Description

This PR adds a document for ADSP Linux showing how to debug the early kernel boot before even the early console can be up and running. This will assist developers who are working on crashing systems.

Testing performed includes running the procedure described in the document to step debug the early kernel booting process from the U-Boot bootloader environment.

Type

  • Documentation
  • Bug fix
  • New feature
  • Continuous integration

Checklist

@Brandon-Hurst
Copy link
Copy Markdown
Contributor Author

@pamolloy You may be interested / have comments in this

@Brandon-Hurst Brandon-Hurst force-pushed the adsp/add-debug-guide branch 3 times, most recently from 0d243ed to fdd422a Compare April 14, 2026 22:28
@analogdevicesinc analogdevicesinc deleted a comment from github-actions Bot Apr 15, 2026
@pamolloy pamolloy added this to ADSP Apr 20, 2026
@pamolloy pamolloy requested review from a team, gastmaier, ozan956 and pamolloy April 20, 2026 10:45
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debug-early-boot.rst
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
file://feature/cfg/tracepoints.cfg \
file://feature/cfg/debug-symbols.cfg
"
# ...
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps include this in fragment in the Yocto meta layer? In Buildroot we already generate a debug image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying you'd like me to make this modification here? Do you want this as the default behavior?
https://github.com/analogdevicesinc/lnxdsp-adi-meta

Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
-ex "target extended-remote localhost:3333" \
-ex "set print pretty on" \
-ex "set pagination off" \
-ex "add-symbol-file $VMLINUX $LOAD_ADDR"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can create something like:

set print pretty on
target extended-remote localhost:3333
add-symbol-file ${VMLINUX} ${LOAD_ADDR}

and I believe LOAD_ADDR is static.

We can also suggest them to copy vmlinux-dbg at location where we run gdb, in here 1027cd5#diff-1d796e9c7f37c59e3cd76a83b6b15b00852abcb170a4143304d76a6bec3be71cR109-R111

If we do that we can also create a file as:

set print pretty on
target extended-remote localhost:3333
add-symbol-file vmlinux-dbg 0xC3000000

@pamolloy
Copy link
Copy Markdown
Collaborator

Thanks @Brandon-Hurst! Definitely some really helpful snippets.

Generally it would be good to remove the Yocto specifics and generic documentation. Assume someone already has a working Kernel build. Try to keep the article as concise as possible. It will help us keep the documentation maintainable in the future.

@pamolloy pamolloy moved this to In Development in ADSP Apr 20, 2026
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Comment thread docs/products/adsp/debugging-early-boot.rst Outdated
Add a document for ADSP Linux showing how to debug the
early kernel boot before even the early console can
be up and running. This will assist developers who are
working on crashing systems.

Testing performed is exactly as described in the document.

Signed-off-by: Brandon Hurst <brandon.hurst@analog.com>
@Brandon-Hurst
Copy link
Copy Markdown
Contributor Author

Thanks @Brandon-Hurst! Definitely some really helpful snippets.

Generally it would be good to remove the Yocto specifics and generic documentation. Assume someone already has a working Kernel build. Try to keep the article as concise as possible. It will help us keep the documentation maintainable in the future.

No problem! It was an interesting task.

My thought in doing this was to follow the current Yocto system. In Yocto, these artifacts are not easy to find, so calling out the specific paths for the Yocto build system could be helpful (otherwise finding the vmlinux file after building linux-adi is tough, for example). My experience is also that it's not straightforward to migrate most tasks between Buildroot and Yocto, so I think having a generic guide that serves both would be difficult.

Do you want it based on Buildroot, and just using menuconfig? I could also make this a separate guide for Yocto and a different one for Buildroot, but I think that would be harder to maintain.

get more information about these commands. Other useful resources are the GDB
documentation and `ADI's GDB Command Reference <https://developer.analog.com/docs/codefusion-studio/latest/tutorials/gdb-tutorial/gdb-commands/>`_.

The below example sets a breakpount while the target is in U-Boot, which gets
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo "breakpount"

-ex "target extended-remote localhost:3333" \
-ex "set print pretty on" \
-ex "set pagination off" \
-ex "add-symbol-file $VMLINUX $LOAD_ADDR"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can create something like:

set print pretty on
target extended-remote localhost:3333
add-symbol-file ${VMLINUX} ${LOAD_ADDR}

and I believe LOAD_ADDR is static.

We can also suggest them to copy vmlinux-dbg at location where we run gdb, in here 1027cd5#diff-1d796e9c7f37c59e3cd76a83b6b15b00852abcb170a4143304d76a6bec3be71cR109-R111

If we do that we can also create a file as:

set print pretty on
target extended-remote localhost:3333
add-symbol-file vmlinux-dbg 0xC3000000

#!/bin/bash
# GDB helper script for SC589-MINI kernel debugging

GDB="/opt/adi-distro-glibc/5.0.1/sysroots/x86_64-adi_glibc_sdk-linux/usr/bin/arm-adi_glibc-linux-gnueabi/arm-adi_glibc-linux-gnueabi-gdb"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we specifically need that gdb instance?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is good practice to make sure that the GDB build is one that matches the toolchain, i.e. the populated SDK from Yocto in this case. It's unlikely that this specific one is need though since the target is ARM in this case. It's possible that using gdb-multiarch or arm-linux-gnueabi-gdb would work, but I still prefer the solution using the toolchain populated by our Yocto tools, primarily because it's also required for OpenOCD and I'm not sure if there are specific things about that toolchain build that if not present could break the process in this document.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no hard requirement for Yocto toolchain for gdb. OpenOCD have ADSP specific changes, so that's need to be from toolchain or self compiled. Im only using gdb-multiarch for debugging as usually it have latest python version for plugins and more features.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also there is hardcoded version of Yocto release, can it be sourced like
. /opt/adi-distro-glibc/5.0.1/environment-setup-cortexa55-adi_glibc-linux
and then no need to specify version each time new release comes

To check whether a given ``vmlinux`` file contains debug symbols, use the
``file`` or ``readelf`` utilities. The following example shows the ``file`` output
for a modified :git-lnxdsp-adi-meta:` v5.0.1 Yocto release <releases/tag/5.0.1-rel+>`
with a :git-linux:`6.12 Linux release <commits/adsp-6.12.0-y+>`, but the
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can point to release also:

      :git-linux:`Release 1 <releases/tag/adsp-6.12.0-1+>`
      :git-linux:`Release 2 <releases/tag/6.12.0-2+>`
      :git-linux:`Release 3 <releases/tag/6.12.0-3+>`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Development

Development

Successfully merging this pull request may close these issues.

5 participants